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Beschreibung 



Die vorliegende Erfindung betrifft ( das oberbegrif f lich Bean- 
spruchte und befafit sich somit mit rekonf igurierbaren multi- 
20 dimensionalen Logikfeldern und cleren Betrieb. 

Rekonf igurierbare Elemente werden abhangig von der auszufiih- 
renden Applikation unterschiedlich und applikationsentspre- 
chend ausgestaltet . Unter einer rekonf igurierbaren Architek- 

25 tur werden vorliegend Bausteine (VPU) mit konf igurierbarer 
Funktion und/oder Vernetzung verstanden, insbesondere inte- 
grierte Bausteine mit einer Mehrzahl von ein- oder mehrdi- 
mensional angeordneten arithmetischen und/oder logischen 
und/oder analogen und/oder speichernden und/oder in- 

30 tern/extern vernetzenden Baugruppen, die direkt oder durch 
ein Bussystem miteinander verbunden sind. 
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Zur Gattung dieser Bausteine zahlen insbesondere systolische 
Arrays, neuronale Netze, Mehrprozessor Systeme, Prozessoren 
mit mehreren Rechenwerken und/oder logischen Zellen und/oder 
kommunikativen/peripheren Zellen (10) , Vernetzungs- und 
Netzwerkbausteine wie z.B. Crossbar-Schalter , ebenso wie be- 
kannte Bausteine der Gattung FPGA, DPGA, Chameleon, VPUTER, 
etc.. Hingewiesen wird insbesondere in diesem Zusammenhang 
auf die folgenden Schutzrechte und Anmeldungen desselben An- 
melders: DE 44 16 881 Al, DE 197 81 412 Al, DE 197 81 483 
Al, DE 196 54 846 Al, DE 196 54 593 Al , DE 197 04 044.6 Al , 
DE 198 80 129 Al , DE 198 61 088 Al , DE 199 80 312 Al, 
PCT/DE 00/01869, DE 100 36 627 Al , DE 100 28 397 Al, 
DE 101 10 530 Al, DE 101 11 014 Al , PCT/EP 00/10516, 
EP 01 102 674 Al, DE 198 80 128 Al , DE 101 39 170 Al , 
DE 198 09 640 Al , DE 199 26 538.0 Al , DE 100 50 442 Al , so- 
wie PCT/EP 02/02398, DE 102 40 000, DE 102 02 044, DE 102 02 
175, DE 101 29 237, DE 101 42 904, DE 101 35 210, EP 01 129 
923, PCT/EP 02/10084, DE 102 12 622, DE 102 36 271, DE 102 
12 621, EP 02 009 868, DE 102 3.$ 272, DE 102 41 812, DE 102 
36 269, DE 102 43 322, EP 02 022 692, PACT40 (Anmelde-NR. 
fehlt noch!) . Auf diese Dokumente wird unten durch die an- 
melderinternen Bezugszeichen Bezug genommen. Diese sind 
hiermit zu Of f enbarungszwecken vollumf anglich eingegliedert . 

Die o.g. Architektur wird beispielhaft zur Verdeutlichung 
herangezogen und im folgenden VPU genannt . Die Architektur 
besteht aus beliebigen arithmetischen, logischen (auch Spei- 
cher) und/oder Speicherzellen und/oder Vernetzungszellen 
und/oder kommunikativen/peripheren (IO) Zellen (PAEs) , die 
zu einer ein- oder mehrdimensionalen Matrix (PA) angeordnet 
sein konnen, wobei die Matrix unterschiedliche , beliebig 



Akte: PACT19PCT 



ausgestaltete Zellen aufweisen kann; auch die Bussysteme 
werden dabei als Zellen verstanden. Der Matrix als ganzes 
oder Teilen davon zugeordnet ist eine Konf igurationseinheit 
(CT, Ladelogik) , die die Vernetzung und Funktion des PA kon- 
5 figuriert. Die CT kann z. B. als dedizierte Einheit gem. 
PACT 0 5 , PACT10, PACT 17 , ausgestaltet sein oder als Host- 
Mikroprozessor nach P 44 16 881.0-53 , DE 102 06 856.9 dem 
. PA zugeordnet bzw. mit oder durch solche realisiert sein. 

10 Die Erfindung beschreibt ein Prozessormodell fur rekonfigu- 
rierbare Architekturen, das in wesentlichen Punkten an das 
Modell eines klassischen Prozessors angelehnt ist. Zum besse- 
ren Verstandnis wird zunachst das klassische Modell naher be- 
trachtet. Dabei wird auf die Betrachtung prozessorexterner 

15 Ressourcen (z. B. Hauptspeicher fur Programm und Daten etc.) 
verzichtet . 

Ein Prozessor fuhrt in einem Prozeti ein Programm aus. Das 
Programm besteht dabei aus einer endlicjien Menge von Befehlen 
20 (Diese Menge darf Elemente mehr'fach enthalten) sowie Informa- 
tionen iiber die Reihenfolge, in der Befehle auf einanderf olgen 
konnen. Diese Reihenfolge wird primaruber die lineare Anord- 
nung der Befehle . im Programmspeicher und die Ziele von 
Sprungbef ehlen festgelegt. . 

25 

Befehle werden dabei ublicherweise uber ihre Adresse identi- 
fiziert. Als Beispiel zeigt Figur 1 (a) ein Programm in VAX- 
Assembler zur Exponentiation. 

30 Man kann ein Programm auch als gerichteten Graphen auffassen, 
wobei die Befehle die Knoten bilden, und die Reihenfolge als 
Kanten des Graphen modelliert wird. Dieser Graph wird in Fi- 

3 
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gur 1 (b) gezeigt. Der Graph besitzt dabei einen eindeutigen 
Start- und einen eindeutigen Endknoten. (Im Bild nicht ge- 
zeigt, durch die Pfeile angedeutet.) Die Kanten konnen zu- 
satzlich mit Ubergangswahrscheinlichkeiten markiert werden. 
Diese Information kann dann zur Sprungvorhersage genutzt wer- 
den. Die Sprungvorhersage kann wiederum verwendet werden, um 
Konfigurationen in den Speicher der CT einer VPU vorzuladen 
(vgl. Patentanmeldung PACT10, die zu Of f enbarungszwecken 
vollumf anglich eingegliedert ist) und/oder Konfigurationen in 
den Konf igurationsstack einer PAE vorzuladen (gemali Patentan- 
meldungen PACT13 , PACT 17 , PACT 31 , die zu Of f enbarungszwecken 
vollumf anglich eingegliedert sind) . Durch das Vorladen von 
Konfigurationen in den lokalen Speicher der CT (vgl. PACT10, 
17) und/oder in den PAE-lokalen Konf igurationscache ( PACT17 , 
31) konnen die Konfigurationen dann bei Bedarf schneller ab- 
gerufen werden, was zu einer erheblichen Ef f izienzsteigerung 
f uhrt . 



Durch die lineare Anordnung der Befehle im Speicher ergeben 
sich mehr Abhangigkeiten als unb : edingt notwendig. So sind z. 
B. im gezeigten Beispiel die Befehle DECL und MULL2 voneinan- 
der unabhangig. Dies geht aus dem Graphen in Figur 1 (b) 
nicht hervor. Das Modell kann entsprechend erweitert werden 
durch Aufteil- und Zusammenf assungsknoten . Dies ist in Figur 
1 (c) gezeigt . 

Heutige Prozessoren erkennen derartige Moglichkeiten der Par- 
allelausfiihrung schon zum Teil in Hardware und verteilen die 
Operationen auf verschiedene Rechenwerke. Fur die weiteren 
30 Betrachtungen wird das Modell aus Figur 1(b) verwendet. Die 
Behandlung der zusatzlichen Komplexitat des Aufteilens und 
Zusammenf assens wird auf einen "spateren Zeitpunkt verschoben. 

4 
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Ein Prozeli braucht zu seiner Ausfuhrung aulier dem Programm 
weitere Ressourcen. Diese sind innerhalb des Prozessors die 
Register und die Status-Flags. 

Diese Ressourcen dienen dazu, Inf ormationen zwischen den ein- 
zelnen Befehlen des Programms zu ubermitteln. Es ist Aufgabe 
des Betriebssystems, dafur zu sorgen, dafi einem Prozeli die zu 
seiner Ausfuhrung benotigten Ressourcen zur Verfugung stehen 
und bei seiner Beendigung wieder freigegeben werden. Heutige 
Prozessoren besitzen iiblicherweise nur einen Registersatz, so 
dali nur ein Prozeli gleichzeitig auf dem Prozessor ablaufen 
kann. Es ist nachvollziehbar , dali die Befehle von zwei unter- 
schiedlichen Prozessen in beliebiger Reihenfolge durchmischt 
ausgefuhrt werden konnen, solange beide Prozesse disjunkte 
Ressourcen verwenden (so, wenn z. B. Prozeli 1 die Register 0- 
3 und Prozeli 2 Register 4-7 verwendet) . 

Befehle eines Prozessors haben iiblicherweise die folgenden 
Eigenschaf ten: 

- Ein Befehl wird wahrend der Ausfuhrung nicht unterbrochen . 

- Die Ausfuhrungszeit aller Befehle uberschreitet einen ge- 
wissen Maximalwert nicht. 

- Ungultige Befehle werden vom Prozessor erkannt. 

Die Aufgabe der Erfindung besteht darin, Neues fur die ge- 
werbliche Anwendung bereitzustellen . 

Die Losung der Aufgabe wird unabhangig beansprucht . Bevor- 
zugte Ausfuhrungsf ormen finden sich in den Unteranspriichen . 



2 Ubertragung des Modells auf die VPU-Architektur 

Die beispielhafte VPU-Architektur ist eine rekonf igurierbare 
Prozessorarchitektur, die wesentlich durch die Patent (e) (bzw . 
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Anmeldungen PACT01, 02, 03, 04, 05, 07, 08, 09, 10, 13, 17, 
22, 23, 24, 31 definiert ist. Diese Schriften werden, wie 
vorerwahnt, zu Of f enbarungszwecken vollumf anglich eingeglie- 
dert. Ebenfalls wird auf PACT11, 20, 27 verwiesen, in denen 
5 entsprechende Hochsprachen-Compiler beschrieben sind, sowie 
auf PACT 21, worin ein" entsprechender Debugger beschrieben 
ist. Auch diese Schriften werden zu Of f enbarungszwecken voll- 
standig eingegliedert . 

10 Der klassische Befehl wird ersetzt durch eine Konf iguration 
im bekannten Sinne, im folgenden Komplex-Bef ehl (Complex In- 
truction Word, CIW) genannt. Die Kanten der Graphen in Figur 
1 (b) werden realisiert durch Triggersignale an die CT . Damit 
kann ein vollstandiges Programm realisiert werden, indent nach 

15 der erfolgten Abarbeitung eines CIW die CT und/oder der Kon- 
f igurationscache der PAEs (s. PACT 31 und/oder wie nachfolgend 
beschrieben) das nachfolgende CIW ladt. 

Es wurde zunachst erkannt, wie eine Entsprechung von Regi- 
stern herkommlicher Prozessoren auf der VPU-Architektur ge- 
20 staltet werden kann. Dabei wurde herausgef unden, daJi eine we- 
sentliche Vorrausset zung zur Registerimplementierung auf fol- 
gendem beruht: 

- Da die VPU im wesentlichen auf Datenstromen arbeitet, muft 
ein Register in der Lage sein, einen Datenstrom bzw. Teile 

25 davon zu speichern. 

- Ein Register mufi alloziert und freigegeben werden konnen. 
Dabei mufi es so lange belegt bleiben wie das Programm auf der 
VPU lauft. (HW-Unterstutzung der Ressourcenverwaltung des Be- 
triebssystems . ) 

30 - Gleichzeitiges Lesen und Schreiben (Read-Modif y-Write) des- 
selben Registers sollte moglich sein. 
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Es wird eine angegeben, wie dies in einem Prozessor erreicht 
werden kann und es wird weiter erf indungsgemafi vorgeschlagen, 
entsprechend modif izierte RAM-PAEs zu verwenden. Diese sollen 
zunachst als Register verwendet werden. 

Eine ausfuhrliche Beschreibung der Register-PAEs bevorzugt 
durch erweiterte und/oder modif izierte RAM-PAREs ist nachfol- 
gend in Abschnitt 4 gegeben. Eine Konf iguration (CIW) wird in 
dem Moment vom Array entfernt, in dem sie uber einen Trigger 
an die CT das nachste CIW anfordert. Der Reconf ig-Trigger 
(vgl. PACT 08 ) kann dabei entweder uber den Reconf ig-Port ei- 
ner ALU-PAE oder implizit durch die CT erzeugt werden. In op- 
timal ausgestalteten Versionen sollte dies grundsat zlich von 
der CT aus erfolgen. 

Ebenso wie Befehle auf einem klassischen Prozessor nicht un- 
terbrochen werden, lauft bevorzugt auch ein CIW auf der VPU 
ohne Unterbrechung bis es das nachste CIW uber einen Trigger 
an die CT anfordert. Es wird nicht vorzeitig beendet. Urn den- 
noch einen regelmaliigen Bef ehlswechsel sicherstellen zu kon- 
nen (dieser wird spater fur Multitasking benotigt) , wird die 
maximale Ausf uhrungszeit eines CIW nach oben beschrankt. Da- 
mit wird die zweite Eigenschaft eines Befehls gefordert. Es 
ist bevorzugt die Aufgabe des Compilers, dafur zu sorgen, dafl 
jedes erzeugte CIW dieser Bedinguhg genugt . Ein CIW, das die- 
se Bedingung verletzt,.. ist ein ungultiger Befehl. Er kann von 
der Hardware wahrend der Ausfuhrung z. B. iiber einen 
Watchdog-Timer der nach Ablauf einer bestimmten Zeit einen 
Trigger quasi als Warnsignal generiert, erkannt werden. 

Bevorzugt wird das Warnsignal als TRAP durch die Hardware 
und/oder das Betriebssystem verwaltet. Ebenfalls bevorzugt 
wird das Signal an die CT gesendet. Ein ungultige CIW bevor- 



Akte: PACT19PCT 



zugt uber einen Reconf ig-Trigger , der das reset-ahnliche L6- 
schen samtlicher Konf igurationen im PA bewirkt, beendet 
und/oder ebenfalls bevorzugt eine Exception an das Betriebs- 
system geschickt. 

5 

Da die CIWs sehr lang sind, sind dementsprechend auch die In- 
struction-Fetch- ( Zeit zwischen Rekonf igurations-Trigger der 
PAEs an die CT (vgl. PACT08 ) und Konfguration ist im FILMO- 
Cache geladen) und Instruction-Decode-Zeiten (Verteilung der 

10 Konf igurations-Daten vom FILMO-Cache (siehe PACT10) in die 
Konf igurations-Register der PAEs) sehr lang. Dadurch ist die 
Auslastung der Execution Units (also dem PA im VPU- 
Prozessormodell) durch einen Prozefl nicht sehr hoch. Wie die- 
ses Problem mit mehreren Prozessen gelost werden kann, wird 

15 nachfolgend in Abschnitt 6 gezeigt. 



3 Unterprogramme 

Ein Unterprogramm in der Graphendarstellung ist ein Teilgraph. 

20 eines Programms mit eindeutig b^stimmten Eingangsknoten . Die 
Kante des Unterprogrammauf ruf s innerhalb des Graphen ist da- 
durch statisch bekannt. Die weiterf uhrende Kante am Ausgangs- 
knoten des Unterprogramms ist jedoch nicht statisch bekannt. 
In Figur 2 wird dies verdeutlicht . Die Kanten vom Hauptpro- 

25 gramm (0201/0202) zum Unterprogramm (0205) sind vorhanden, 

die Fortfuhrung (0206) nach dem Unterprogramm ist jedoch dem 
Unterprogramm 0205 nicht bekannt. Die jeweilige Fortfuhrung 
ist fest mit dem Unterprogrammauf ruf verbunden (durch gestri- 
chelte bzw. gepunktete Linien markiert) . Sie muli vor dem Er- 

30 reichen des Eingangsknotens in geeigneter Weise in den Gra- 
phen eingefugt werden (0207, 0208) . Dies ist in Figur 3 ver- 
deutlicht. 



8 
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In klassischen Prozessoren geschieht dies ublicherweise da- 
durch, dafi beim Unterprogrammauf ruf (Call, 0203, 0204) die 
Adresse des auf das Unterprograitun folgenden Befehls (das ist 
genau die fehlende Kante) auf einem Call-Stack abgelegt wird. 
5 Von dort kann sie beim Riicksprung (Return) geholt werden. 

Ubertragen auf die VPU wird also prinzipiell eine Stack-PAE 
benotigt. Dies ist genauso wie die Register-PAEs eine Prozeli- 
Ressource und wird genauso verwaltet. Das CIW, das bei seiner 
10 Beendigung den Unterprogrammauf ruf veranlalit, konfiguriert 
die Rucksprung-Kante auf das Stack-PAE. Durch einen Trigger 
veranlalit das letzte CIW des Unterprogramms das Stack-PAE, 
den obersten Eintrag vom Stack zu entfernen und als Rekonfi- 
gurationsauf ruf an die CT zu schicken. 

15 

Bei der Implementierung eines Stacks kann beispielsweise eine 
der nachfolgende Methoden angewendet werden: 

- Eine Losung innerhalb der CT. Der Stack wird innerhalb der 
20 CT in Software oder als dediziearte Hardwareeinheit realsiert. 
Dabei kann eine spezielle Config-ID (z. B. -1) als Riicksprung 
reserviert sein. Wenn der CT diese ID erhalt, ersetzt er sie 
durch den obersten Eintrag seines lokal verwalteten Stacks. 

25 - Eine Stack-PAE, die beispielsweise als eine modif izierte 
RAM-PAE nach PACT 1 3 Fig. 21 aufgebaut sein kann. 
Stack-Overflow sowie Stack-Underflow sind Exceptions, die be- 
vorzugt an das Betriebssystem weitergegeben werden. 

30 4 Das Register-PAE 

Ein klassisches Prozessorregister enthalt zu jedem Zeitpunkt 
ein Datenwort. Ein Befehl kann 'den Registerinhalt lesen, 
schreiben oder verandern (Read-Modif y-Write) . 
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Ein VPU-Register wird nun die gleichen Eigenschaf ten aufwei- 
sen, allerdings enthalt es statt eines einzelnen Wertes er- 
findugnsgemali einen Wertevektor oder Teile davon. Es sit mog- 
lich und ublicherweise bevorzugt, dali die Organisation eines 
VPU-Registers als eine Art FIFO erfolgt. In bestimmten Fallen 
kann aber auch wahlfreier Zugriff erforderlich werden. Im 
folgenden werden die drei oben angesprochenen Registerzugrif- 
fe im einzelnen erlautert. Dabei wird ein wahlfreier Zugriff 
hier nicht betrachtet. 

Lesezugriff Beim Start eines CIW enthalt das Register einen 
Datenvektor unbekannter Lange . Die einzelnen Elemente des 
Vektors werden sequentiell entnommen . Dabei wird beim letzten 
Element des Vektors ein Trigger generiert, der anzeigt, dass 
das Register jetzt leer ist und das CIW terminieren kann. Der 
Zustand des Registers kann dabei mit 3 Zeigern charakteri- 
siert werden, sie zeigen auf den ersten (0403), letzten 
(0401) und aktuellen (0402) Eintrag im Datenvektor. Die Stel- 
lung der Zeiger zu Beginn eines; : CIW wird beispielhaft in Fi- 
gur 4 (a) gezeigt. Dabei steht der Zeiger fur den aktuellen 
Eintrag auf dem ersten Eintrag. 

Figur 4 (b) zeigt in einem Beispiel, wie die Zeigerstellung 
eines Registers am Ende eines CIW "aussehen kann. Im dort ge- 
zeigten Fall wurde der Vektor nicht vollstandig gelesen. 

Folglich mull entschieden werden, was mit dem Registerinhalt 
geschieht. Es gibt bevorzugt die folgenden Moglichkeiten : 
- Das Register wird geleert. Alle nicht verarbeiteten Daten 
werden geloscht. Der Zeiger fur den aktuellen Eintrag wird 
auf den letzten Eintrag gesetzt. 
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- Das Register wird auf den Ursprungszustand zuruckgesetzt. 
Dadurch kann das nachste CIW wieder auf den vollen Datenvek- 
tor zugreifen. Der Zeiger fur den aktuellen Eintrag wird auf 
den ersten Eintrag zuruckgesetzt. 

- Nur die bereits gelesenen Daten werden aus dem Register 
entfernt. Die ungelesenen Daten stehen fur das nachste CIW 
zur Verfugung. Die Zeiger werden dabei nicht verandert. 

Im Anschlufi daran werden die Werte zwischen dem ersten Ein- 
trag und dem aktuellen Eintrag aus dem Register entfernt. Sie 
stehen fur weitere Operationen nicht mehr zur Verfugung. 

Die dritte Moglichkeit ist insbesondere dann interessant, 
wenn ein CIW aufgrund der maximalen Ausf uhrungszeit fur ein 
CIW den Datenvektor nicht vollstandig verarbeiten kann. Siehe 
hierzu auch Abschnitt 7 . 

Schreibzugriff Hier werden Daten sequentiell in das Register 
geschrieben. Dabei wird ein Trigger generiert, wenn der Full- 
stand des Registers einen bestimmten Wert erreicht. Je nach 
CIW kann dies eine der folgendea bevorzugten Moglichkeiten 
sein: 

- Das Register ist vollstandig gefullt. 

- Es sind noch genau n Eintrage im Vektor f rei . Dies beriick- 
sichtigt die Latenzzeit im CIW, durch die noch n Werte nach 
dem Trigger auf das Register laufen. 

- Das Register ist zu m% gefullt. 

Ein CIW, das versucht, auf ein vollstandig gefulltes Register 
zu schreiben, ist ungiiltig und wird mit einer Exception been- 
det (Illegal Opcode) . Beim Start des CIW soli festgelegt 
sein, in welchem Zustand sich das Register befindet. Figur 5 
(a) zeigt ein Register vor einem Schreibzugriff, das noch Da- 
ten enthalt. Es wird vorgeschlagen, daft bestehende Daten kon- 

11 
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nen geloscht werden, so dafi der Schreibzugrif f mit einem lee- 
ren Vektor beginnt (Figur 5 (b) ) . Alternativ konnen die ge- 
schriebenen Daten auch an den bestehenden Inhalt angehangt 
werden. Dies zeigt Figur 5 (c) . Dies ist dann interessant, 
wenn das vorhergehende CIW nicht den kompletten Vektor erzeu- 
gen konnte aufgrund der maximalen Ausf uhrungszeit . 

Der Zustand des Registers nach erfolgter Schreiboperation 
zeigt Figur 5 (d) bzw. (e) . Die neu geschriebenen Daten sind 
dabei schraffiert gekennzeichnet . 

paralleler Schreib-/Lesezugrif f Die Beschrankung auf reine 
Schreib- bzw. Lesezugriffe erfordert eine hohere Registerzahl 
als notig. Wenn einem Register durch Lesezugriffe Daten ent- 
nommen werden, entsteht dadurch Platz, in dem Schreibdaten 
auf genommen werden konnen. Es muIS lediglich sichergestellt 
werden, dass geschriebene Daten nicht vom gleichen CIW wieder 
gelesen werden konnen, d.h. dass eine klare Trennung zwischen 
den Lesedaten eines CIWs und den Schreibdaten des CIWs exi- 
stiert. Dazu wird in den FIFO eine virtuelle Trennlinie 
(0601) eingefuhrt. Das Register wurde vollstandig gelesen, 
wenn diese Trennlinie am Ausgang des FIFOs angelangt ist. Zur 
Festlegung dieser virtuellen Trennlinie konnen geeignete Mit- 
tel implement iert sein. 

Kann ein Schreibzugrif f fur ein Datenwort nicht ausgeflihrt 
werden, weil das Register noch mit ungelesenen Lesedaten 
blockiert ist, wird das CIW beendet und eine Illegal Opcode 
Exception erzeugt. Das Verhalten des Registers ist ansonsten 
genauso wie bei Schreib- und Lesezugriff erlautert. 
Zusatzlich soil spezifiziert werden, was mit der virtuellen 
Trennlinie zwischen Lese- und Schreibdaten geschieht. Diese 
kann entweder an der Stelle verbleiben, wo sie gerade steht. 



12 
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Dies ist dann niitzlich, wenn ein CIW aufgrund der Zeitbe- 
schrankung beendet werde mufi . Alternativ wird die Trennlinie 
an das Ende aller Daten gesetzt. 



5 Kombinierte Schreib-/Lesezugrif f e sind allerdings problema- 
tisch, wenn das CIW mit einer Exception beendet wurde. In 
diesem Fall ist es nicht mehr ohne weiteres moglich, die Re- 
gister auf ihre Werte beim Start des CIW zuriickzustellen . Das 
Debugging kann dadurch zumindest erschwert werden, siehe auch 

10 nachfolgend in Abschnitt 8. 

Figur 6 zeigt die Funktionsweise an einem Beispiel. 0601 
kennzeichnet die virtuelle Trennlinie. Zu Beginn enthalt das 
Register Daten (a), die im folgenden teilweise (b) bzw. voll- 

15 standig (c) gelesen werden. Neu geschriebene und gelesene 

Eintrage sind dabei durch unterschiedliche Schraffur gekenn- 
zeichnet. Die Teilbilder (d) und (e) zeigen den Zustand des 
Registers nach dem notwendigen Zeiger-Update, das die Trenn- 
linienlage verandert. Dies ist kein expliziter Schritt, son- 

20 dern wird hier nur zur Verdeutli ; chung dargestellt. Die gele- 
senen Eintrage mussen sofort entfernt werden, urn Platz fur 
die neu zu schreibenden Eintrage zu schaffen. 

Ein Prozefi, also ein Programm, das auch insbesondere bei ei- 

25 nem Multitasking-Betrieb Ressourcen mit anderen Programmen 

teilt, muli jedes benotigte Register allozieren, bevor er es 

verwenden kann. Dies geschieht bevorzugt uber ein zusatzli- 

ches Konf igurationsregister innerhalb der RAM- und/oder Regi- 

ster-PAE. Dort wird auch eingetragen, zu welchem Prozefi das 

30 Register jetzt gehort. Diese Konf iguration bleibt auch uber 

Rekonf igurationen hinweg erhalten. Das Register mufi explizit 

vom CT freigegeben werden. Dies geschieht beispielsweise bei 

der Beendigung eines Prozesses. Mit der Konf iguration jedes 
13 
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CIWs muli den Registern mitgeteilt werden, zu welchem Prozefi 
das CIW gehort. Dies ermoglicht das Umschalten zwischen meh- 
reren Registersatzen . Das Verfahren wird nachfolgend genauer 
im Abschnitt 6 beschrieben. 

5 



5 Interrupts 

Bei Interrupts muB zwischen zwei unterschiedlichen Typen un- 
terschieden werden. Zum einen gibt es die Hardware- 

10 Interrupts, wo der Prozessor auf ein externes Ereignis rea- 
gieren muli. Diese werden ublicherweise vom Betriebssystem be- 
arbeitet und sind fur die laufenden Prozesse nicht sichtbar. 
Sie sollen hier nicht weiter behandelt werden. Der zweite Typ 
sind die Software-Interrupts. Diese werden haufig benutzt, um 

15 asynchrone Interaktionen zwischen Prozefi und Betriebssystem 
zu realisieren. So ist es z. B. unter VMS moglich, eine Lese- 
anforderung an das Betriebssystem zu schicken, ohne auf die 
eigentlichen Daten zu warten. Sobald die Daten vorhanden 
sind, unterbricht das Betriebssystem das laufende Programm 

20 und ruft asynchron eine Prozedua; des Programms auf. Dieses 
Verfahren nennt sich dort Asynchronous System Trap (AST) . 

Dieses Verfahren kann in gleicher Form auf der VPU angewendet 
werden. Hierzu kann Unterstutzung im CT vorgesehen werden. 
Der CT weifi, ob eine asynchrone Routine fur einen Prozefi auf- 
gerufen werden mufi . In diesem Fall wird der nachste Request, 
der vom Array kommt, nicht direkt abgearbeitet , sondern ge- 
speichert . 

30 Stattdessen wird eine Folge von CIWs eingefiigt, die zunachst 
die Prozessorstatus (die Registerinhalte) sichern, die asyn- 
chrone Routine ausfuhren und dann die Registerinhalte wieder- 
herstellen. Im Anschlufi daran kann der ursprungliche Request 
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abgearbeitet werden. 



6 Multitasking 

In Abschnitt 2 wurde f estgestellt, dafi die VPU-Architektur 
mit nur einem ProzeJi unter Umstanden nicht optimal ausgela- 
stet werden kann, weil etwa aufgrund der Lange der CIWs sehr 
hohe Lade- und Dekodierungszeiten auftreten. Dieses Problem 
kann durch die gleichzeitige Ausfiihrung mehrerer Prozesse ge- 
lost werden. Hierbei werden auf der VPU nun erf indungsgemali 
mehrere Registersatze vorgesehen, was erlaubt, dafi beim Kon- 
textwechsel einfach zwischen den Registersatzen umgeschaltet 
werden kann und keine aufwendigen Register-Freiraum- und - 
Lade-Operationen erforderlich werden. Die Verarbeitungsge- 
schwindigkeit kann so erhoht werden. 

Wahrend der Ausfiihrung von CIWs der Prozesse steht genugend 
Zeit zur Verfiigung, urn den nachsten Befehl des aktuellen Pro- 
zesses zu holen und liber den FILMO an die PAEs zu verteilen, 
bzw. aus dem Konf igurationscache in die PAEs zu laden (vgl 
PACT31) . Die optimale Anzahl an Registersatzen kann dabei in 
Abhangigkeit von der durchschnittlichen Ausf uhrungszeit eines 
CIW und den durchschnittlichen Lade- und Dekodierzeiten der 
CIWs bestimmt werden. 

Dabei kann Latenzzeit durch eine grofiere Anzahl Registersatze 
abgefangen werden. Wichtig fur die Funktion des Verfahrens 
ist, dafi die durchschnittliche CIW-Laufzeit grofier ist als 
die jeweils effektiv benotigte Zeit zum Laden bzw. Dekodieren 
des CIW. 

Die korrespondierenden Register der unterschiedlichen Regi- 
stersatze liegen dabei fur den Programmierer auf derselben 
15 
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PAE-Adresse. D.h. es konnen zu jedern Zeitpunkt inutier nur die 
Register eines Registersat zes verwendet werden. Der Kon- 
textwechsel zwischen den Registersatzen kann dadurch reali- 
siert werden, dass vor jedem CIW der entsprechende Kontext an 

5 die PAEs ubertragen wird. Der Kontextswitch kann im Detail 

durch die PUSH/POP Operationen nach PACT11 und/oder durch ei- 
ne besondere RAM-/Register-PAE Hardware wie in PACT 13 Fig. 21 
dargestellt automatisch erfolgen. In beiden Fallen ergibt 
sich ein ahnlicher Stack-Aufbau im Speicher. Jeder Stack- 

10 Eintrag speichert die Daten eines Prozesses. Ein Stackeintrag 
umfafit dabei den kompletten Inhalt aller Registers, mit ande- 
ren Worten samtlicher Speicherzellen aller Speicher die als 
Register fur einen Prozess dienen. Ebenso kann gemali PACT11 
ein Stackeintrag auch PA-interne Daten und Zustande enthal- 

15 ten. 

Im allgemeinen werden nun auf einem System mehr Prozesse vor- 
handen sein als Registersat ze auf dem Prozessor. Das bedeu- 
tet, dafi gelegentlich ein Prozeli vom Prozessor entfernt wer- 

20 den muli. Dazu wird ahnlich wie b : eim Software-Interrupt eine 
Kante den Programmgraphen vom CT auf getrennt . Die Registerin- 
halte des Prozesses werden gesichert und die vom ProzeB allo- 
zierten Prozessorressourcen i (Register, Stack-PAE, etc.) wie- 
der freigegeben. Die so f reigewordenen Ressourcen werden nun 

25 von einem anderen Prozeli alloziert*. Dann werden die fur die- 
sen ProzeB gespeicherten Registerinhalte wieder zuriickge- 
schrieben und der Prozeli an dessen auf getrennter Kante fort- 
gesetzt. Das Sichern und Riickladen der Registerinhalte kann 
dabei uber CIWs erfolgen. 

30 

7 CIW und Schleif en 
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Aufgrund der oben geforderten Eigenschaft, dafi ein CIW spate- 
stens nach einer gewissen Maximalanzahl an Takten terminieren 
mufi, konnen allgemeine Schleifen nicht ohne weiteres in ein 
CIW ubersetzt werden. Es ist immer moglich, den Schleif en- 
rumpf in ein CIW zu ubersetzen und die Schleif enkontrolle 
uber Rekonf iguration abzuwickeln. Dies kostet jedoch oftmals 
erheblich Performance. Dieser Abschnitt zeigt, wie eine 
Schleife so umgeformt werden kann, daft die Anzahl der Rekon- 
figurationen minimiert wird. 

Im folgenden wird von folgendem Programmstuck ausgegangen: 



while (condition) { 
something; 
15 } 

Dabei soli sowohl die Laufzeit von condition wie something 
bestimmt oder nach oben abgeschatzt werden konnen. Die 
Schleife kann nun wie folgt umf ormuliert werden: 
20 V 
while (1) { 

if (! condition) goto finish; 

something; 

} 

25 finish: 

Nun kann der Schleif enrumpf so oft iteriert werden, wie es 
die maximale Laufzeit eines CIW zulafit. Hierzu wird eine neue 
Variable z eingefuhrt, die weder in condition noch in some- 
30 thing vorkommt . Das Programm sieht nun f olgendermafien aus: 

while (1) { 

for ( z=0 ; z<MAX; z++ ) { 

17 
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if (! condition) goto finish; 

something; 

} 

} 

5 finish: 

Die for-Schleife besitzt eine vom Compiler bestimmbare maxi- 
male Laufzeit. Sie kann deshalb auf ein CIW abgebildet wer- 
den. MAX wird vom Compiler in Abhangigkeit von der maximalen 
10 Laufzeit und den Einzellauf zeiten der Anweisungen bestimmt. 

Das so entstehende CIW hat zwei Ausgangskanten. Der Ausgang 
uber das goto fuhrt zum nachsten CIW, der Ausgang uber das 
regulare Ende des for bildet eine Kante auf sich selbst. Dar- 
15 uber wird die Endlosschleif e realisiert. 



8 Debugging 

20 ' Im klassischen Prozessor erfolgt das Debugging auf Befehlsba- 
sis, d. h. der Ablauf eines Programms kann jederzeit zwischen 
zwei Befehlen unterbrochen werden. An diesen Unterbrechungs- 
punkten hat der Programmierer Zugriff auf die Register. Er 
kann sie ansehen und modif izieren. Unterbrechungspunkte kon- 

25 nen auf verschiedene Art und Weise' realisiert werden. Zum ei- 
nen kann das Programm modif iziert werden, d. h. der Befehl, 
vor dem angehalten werden soil, wird durch andere Befehle er- 
setzt, die den Debugger aufrufen. Im Graphenmodell entspricht 
dies dem Austausch eines Knotens durch einen anderen Knoten 

30 oder einen Teilgraphen. Eine andere Methode beruht auf zu- 

satzlicher Hardware-Unterstutzung . Hierbei wird dem Prozessor 
mitgeteilt, bei welchem Befehl *das Programm unterbrochen wer- 
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den soil. Der entsprechende Befehl wird dabei ublicherweise 
iiber seine Adresse identif iziert . 

Beide Moglichkeiten sind auf die VPU erf indungsgemafi uber- 
tragbar. Ein CIW kann etwa vom Debugger durch ein anderes CIW 
ersetzt werden. Dieses CIW kann z. B. die Registerinhalte in 
den Hauptspeicher kopieren, wo diese entweder mit einem VPU- 
externen Debugger analysiert werden konnen. Alternativ kann 
der Debugger auch auf der VPU ablaufen. 

Weiterhin kann eine Hardware-Unterstut zung im CT vorgesehen 
werden, die CIWs bei deren Request anhand der ID identifi- 
ziert und dann den Debugger aufruft. Zusatzlich kann eine Un- 
terbrechung auch ein einer Kante des Graphen festgemacht wer- 
den, da diese im Gegensatz zu klassischem Programmcode expli- 
zit vorliegen. 



Die oben beschriebene Art des Debugging ist fur klassische 
Prozessoren vollstandig ausreichend, da die Befehle zumeist 
20 sehr einfach sind- Eine hinreichend feine Auflosung der beob- 
achtbaren Punkte ist gegeben. Weiterhin kann sich der Pro- 
grammierer darauf verlassen, dafi die einzelnen Befehle kor- 
rekt sind- (Dafiir sorgt ublicherweise der Prozessorherstel- 
ler. ) 

25 

Auf der VPU hingegen ist es dem Programmierer moglich, sich 
die CIWs zu definieren, welche eine Art "Prozessorbef ehle" 
bilden. Dementsprechend konnten die so definierten in sich 
Befehle fehlerhaft sein. Ein Debugging der einzelnen Befehle 
30 wird also bevorzugt auf eine im folgenden als Microcode- 
Debugging bezeichnete Weise ausgelegt. Microcode-Debugging 
ist so ausgestaltet , daft der Programmierer Zugriff auf alle 

internen Register und Datenpfade des Prozessors erhalt; es 

19 



Akte: PACT19PCT 



wurde erkannt, daft der dafur erf orderliche Aufwand ohne wei- 
teres durch die gesteigerte Funktionalitat zu rechtf ertigen 
ist . 

Eine Hardware-Unterstiitzung hierfur ist moglich, aber sehr 
aufwendig und zu reinen Debugging-Zwecken nicht sinnvoll. Al- 
ternativ wird daher der Zustand des Prozessors vor dem frag- 
lichen Befehl gesichert werden und die Ausfuhrung des eigent- 
lichen Befehls auf einem Software-Simulator erfolgen. Dies 
ist die nach PACT11 bevorzugte Methode zum Debuggen von VPUs. 
Die Daten und Zustande werden uber Businterf ace , Speicher 
und/oder bevorzugt uber Debug-Interf ace wie z.B. JTAG an den 
Debugger ubertragen. Bevorzugt kommt ein Debugger nach PACT 21 
zum Einsatz, der zur Abarbeitung des Micro-Debuggings bevor- 
zugt einen Mixed-Mode Debugger mit integriertem Simulator 
enthalt. 

Bei geeignetem Programmiermodell kann der Debugger auch bei 
Auftreten einer Exception innerhalb eines Befehls aufgerufen 
werden. Hierzu ist es sinnvoll , . jdass die Register auf den Zu- 
stand vor dem Start des Befehls zuruckgestellt werden konnen 
und sonst keine Seitenef f ekte aufgetreten sind. Dann kann der 
fragliche Befehl im Software-Simulator gestartet werden und 
bis zum Auftreten der Exception simuliert werden. 

Besonders bevorzugte Debugging-Mechanismen sind in PACT 21 
ausfiihrlich beschrieben. 

Microcode-Debugging kann bevorzugt dadurch realisiert werden, 

dass nach oder wahrend der Abarbeitung eines CIW ein Debug- 

CIW konfiguriert wird, das zunachst samtliche Zustande (z.B. 

in den PAEs) erhalt und diese dann durch eine geeignete Kon- 

figuration der Vernetzungsressourcen in einen externen Spei- 

20 
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cher schreibt- Hierzu konnen besonders bevorzugt die in 
PACT11 beschriebenen PUSH/POP Methoden zum Einsatz gelangen. 
Bevorzugt kann dies uber eine Industriestandard-Interf ace, 
wie z.B. JTAG erfolgen. Aus dem Speicher oder iiber das JTAG- 
5 Interface kann dann ein Debugger die Daten ubernehmen und 
ggf. in Verbindung mit einem Simulator (vgl. PACT21) auch 
schrittweise weitersimulieren, wodurch ein Microcode- 
Debugging ermoglicht wird. 

10 

9 Verteilter Konfigurations-Cache 

Aufgrund des zentralen Konf igurations-Caches beim FILMO dau- 
ert es, wenn ein solches, was nicht zwingend ist , verwendet 
wird, verhaltnismaftig lange, bis eine Konf iguration auf die 
15 einzelnen PAEs einer PAC verteilt ist. Dieser Abschnitt be- 
schreibt nun ein bevorzugtes Verfahren, urn diese Zeit abzu- 
kurzen. Ein ahnliches, alternatives oder zusatzliches Verfah- 
ren ist aus PACT 31 bereits bekannt und ist zu Of f enbarungs- 
zwecken vollumf anglich eingegliedert . 

20 

Dazu erhalt jedes PAE seinen eigenen lokalen Cache. Dieser 
speichert die Konf igurationsdaten verschiedener Konf iguratio- 
nen fur genau dieses PAE. Auch die Tatsache, dali ein PAE von 
einer Konf iguration keine Daten erhalten hat, wird gespei- 
25 chert. Fur jede angeforderte Konf iguration kann der Cache da- 
durch eine der folgenden Aussagen treffen: 

- Die Konf igurationsdaten sind im Cache vorhanden. 

- Fur diese Konf iguration werden keine Daten benotigt. 

- Uber diese Konf iguration ist nichts bekannt. 

30 - Es werden Konf igurationsdaten benotigt, diese sind jedoch 
nicht im Cache verfugbar. (z. B. aufgrund der Lange der Kon- 
f iguration, RAM-Preload etc.) 
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Die letzten beiden Aussagen konnen dabei zusammengef afit wer- 
den. Bei beiden mufi der Code oder die Tatsache, dafi kein Code 
benotigt wird, angefordert werden. Ein Auftrag fur eine Kon- 
figuration wird dabei vom FILMO als Broadcast auf dem Testbus 
an alle PAEs verschickt. Wenn alle PAEs die Konf iguration in 
ihrem lokalen Cache haben, kann diese per Broadcast auf dem 
Configbus gestartet werden. Im Idealfall erfordert der Start 
einer Konf iguration also nur die Ubertragung eines einzigen 
Konf igurationswortes . 

Sollte ein PAE nicht iiber die Konf igurationsdaten verfugen, 
mufi dieses an .dem FILMO zuruckgemeldet werden. Im einfachsten 
Fall geschieht dies iiber ein Reject auf der vorhandendenen 
Leitung. Der FILMO weifi dann aufgrund dieses Signals, dafi 
mindestens einem PAE der PAC die Konf igurationsdaten fehlen. 
Er kann dann die kompletten Daten ubertragen. Alternativ kann 
auch jedes PAE getrennt einen Request fur die Daten auslosen. 
Hier mufi ein geeigneter Kompromifi zwischen der Anzahl der Re- 
quests und der Menge der zu ubertragenden Konf igurationsdaten 
gefunden werden. Kleine PAC-Gr6fl : en sind dabei auch aufgrund 
der geringeren Latenz auf dem Konf igurationsbus von Vorteil. 



Aufbau des Caches 

25 Ein Cache besteht immer aus zwei Tei'len. Der eine Teil ent- 
halt die eigentlichen Daten (hier die Konfigurationsworte, 
0902), der andere Teil enthalt Verwaltungsinf ormation (hier 
die enthaltenen Konf igurationsnummern sowie ihr Alter, 0901) 

30 Zunachst wird der Verwaltungsteil beschrieben. 

Wunschenswert ist, dafi die am langsten nicht mehr benutzte 

Konf iguration aus dem Cache entfernt wird, wenn dies notwen- 
" — ' 22 
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dig wird. Solange nur neue Konf igura-tionen angefordert wer- 
den, sind die Eintrage im FIFO korrekt sortiert. Sollte eine 
Konf iguration angefordert werden, fur die bereits ein Eintrag 
im FIFO vorhanden ist, mufi dieser Eintrag aus dem FIFO ent- 

5 fernt werden. Er wird dann wieder neu am Ende eingefugt. Eine 
beispielhaft fur diesen Zweck modifizierte FIFO-Stufe zeigt 
Figur 7. Die schraf f ierten Module sind dabei zusatzlich zu 
einer normalen FIFO-Stufe nach dem Stand der Technik. Sie 
vergleichen mittels des Vergleichers (0701) die Konf igurati- 

10 onsnummer des Dateninhaltes der Stufe mit der geforderten 
Konf igurationsnummer und erzeugen bei Gleichheit ein ack 
(0702) fur die Stufe. Damit werden die Daten der Stufe liber 
den Multiplexer (0703) gelesen und alle anderen Werte rut- 
schen urn eine Stufe nach. Die Eintrage in diesem FIFO enthal- 

15 ten auBer der Konf igurationsnummer weitere Inf ormationen . 

Dies ist entweder ein Zeiger (Adresse) auf die Konfigurati- 
onsdaten oder eine der beiden Moglichkeiten "keine Daten er- 
forderlich" (z. B. als 0 codiert) bzw. "Daten mussen angefor- 
dert werden" (z. B. -1). Die Zusammenschaltung mehrerer Stu- 

20 fen zeigt Figur 8 . Dabei wird d?Le Read-Chain mit der gefor- 
derten Konf igurationnummer und dem Status -1 initialisiert . 
Dieser Wert kommt unverandert genau dann am Ausgang der Read- 
Chain heraus, wenn die Konf igurationsnummer nicht im FIFO ge- 
speichert ist. Damit kann der Ausgang der Read-Chain in jedem 

25 Fall dazu verwendet werden, die Konf igurationsnummer auf den 
FIFO zu schreiben. Das Signal ack_in wird dann aktiviert, 
wenn der FIFO voll ist und sich die gesuchte Konf igurations- 
nummer nicht im FIFO befindet. Dies ist der einzige Fall, bei 
welchem der alteste Eintrag aus dem FIFO ent fernt werden muli, 

30 weil der Verwaltungsspeicher voll ist. Der eigentliche Daten- 
speicher wird aufgrund der unterschiedlichen Anzahl der Kon- 
f igurationsworter pro Konf iguration als verkette Liste orga- 

nisiert. Andere Im-plementierungen sind denkbar. Eine verket- 

23 
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tete Liste kann als RAM einfach dadurch implementiert werden, 
dali zusatzlich zu den Daten jeweils die Adresse des nachfol- 
genden Datenwortes abgelegt wird. 

Zusatzlich zu den Listen fur die eigentlichen Konf igurationen 
wird eine Frei-Liste gefuhrt, in der alle nicht benutzten 
Eintrage aufgefuhrt sind. Diese muli nach einem Reset zunachst 
initialisiert werden. 

Figur 9 zeigt einen moglichen Cache-Inhalt wahrend des Be- 
triebs. Freie Eintrage im Datenspeicher sind dabei weifi, von 
einer Konf iguration belegte schraffiert unterlegt. Konf igura- 
tionen miissen dabei nicht auf auf einanderf olgenden Adressen 
liegen. Konf iguration 18 besitzt keine Konfigurationsdaten, 
deshalb fuhrt auch kein Zeiger in den Datenspeicher. 

Eine neue Konf iguration wird auf die Freiliste in den Daten- 
speicher geschrieben. Dabei wird die Zeigerinf ormation des 
Datenspeichers nicht modif iziert . Lediglich fur das letzte 
Datenwort ein Konf iguration wire} die Zeigerinf ormation veran- 
dert, urn anzuzeigen, dali die Liste jetzt hier andert . Der 
Zeiger auf die Freiliste wird auf den nachsten Eintrag ge- 
setzt . 

Es kann vorkommen, dass der Plat z in der Freiliste nicht aus- 

reicht, urn die ankommenden Konf igurationsdaten vollstandig 

auf zunehmen. In diesem Fall mufi entschieden werden, ob eine 

alte Konf iguration aus dem Datenspeicher entfernt wird oder 

ob die aktuelle Konf iguration nicht in den Cache auf genommen 

werden soli. Im letzteren Fall werden die nachf olgenden Kon- 

f igurationsworter verworfen. Da keine Zeiger verandert wur- 

den, bleibt die Freiliste wie zuvor, lediglich einige unbe- 

nutzte Datenworter besitzen einen anderen Wert. Die Entschei- 
24 
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dung, welche Konf iguration nicht mehr im Cache liegen soil 
(die alteste oder die aktuelle) kann an der Anzahl der be- 
reits geschriebenen Konf igurationsworte festgemacht werden. 
Es macht wenig Sinn, mehrere gecachete Konf igurationen zu 
5 entfernen, urn Platz fur z. B. eine lange RAM- Initialisierung 
zu schaffen. 

Wenn die alteste Konf iguration entfernt werden soil, wird sie 
dem FIFO entnommen . Der Zeiger des letzten Eintrags der Frei- 
liste wird auf den dem FIFO entnommenen Wert gesetzt. Ab die- 
ser Adresse kann nun in der gewohnten Weise weiterkonf igu- 
riert werden. 

Figur 10 zeigt dies an einem Beispiel. Neu konfiguriert wer- 

15 den soli die Konf iguration mit der Nummer 7. In Figur (a) ist 

die Freiliste vollstandig belegt worden. Es wird entschieden, 

die alteste Konf iguration (Nr. 5) vom Cache zu entfernen und 

Konf iguration Nr. 7 weiter auf den Cache zu schreiben. Dazu 

wird der Zeiger am Ende der Freiliste auf den Start der ehe- 

20 maligen Konf iguration 5 umgesetzt. Dadurch wird die Freiliste 

wieder verlangert und es steht wieder Platz fur neue Konfigu- 

rationsworte zur Verfugung. Die in diesem Schritt betroffenen 

Speicherteile sind in Figur (b) gegendiagonal schraffiert. 

Bei geeigneter Aufteilung des Speichers kann dies in einem 

25 Takt erfolgen. Mit dem letzten Konf igurationswort wird der 

entsprechende Zeiger auf Ende gesetzt und der Freizeiger auf 

den nachsten Eintrag. Platz im Datenspeicher wird nicht nur 

dann wieder freigegeben, wenn dieser durch die Aufnahme einer 

neuen Konf iguration benotigt wird. Auch wenn der Verwaltuns- 

30 speicher voll ist und deswegen ein Eintrag vom Verwaltungs- 

speicher entfernt wird, mufi die Freiliste im Datenspeicher 

angepafit werden. Hierzu mull entweder der Zeiger am Ende der 

Freiliste oder am Ende der f reiwerdenden Konf iguration ange- 
25 
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palit werden. Beide Inf ormationen stehen bisher nicht zur Ver- 
fugung. Man kann sich jetzt durch eine der Listen durchbewe- 
gen, bis das Ende erreicht wird. Dies ist jedoch zeitaufwen- 
dig. Alternativ wird im Verwaltungsspeicher ein zusatzlicher 
Zeiger auf das jeweilige Ende einer Konf iguration abgelegt. 
Nun ist die Modifikation einfach moglich. Der Freizeiger er- 
halt die Startadresse der alten Konf iguration, und der Zeiger 
beim letzten Konf igurationswort im Datenspeicher wird auf den 
Freizeiger gesetzt . 

Dies wird in Figur 11 verdeutlicht . Die Zeiger auf die Konfi- 
gurationsenden sind dabei gestrichelt eingezeichnet . UnterFi- 
gur (a) zeigt die Situation vor dem Loschen, UnterFigur (b) 
die danach. 
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10 Optimierung der Busallokation 

Derzeit werden die Busse explizit vom Router festgelegt. Das 
kann dazu fuhren, dafi zwei Konf igurationen sich auf einem Bus 
20 uberlappen und deswegen nicht gl ; eichzeitig ablaufen konnen, 
obwohl insgesamt genugend Busse zur Verfugung stunden. 

Es wurde erkannt, dafi es algorithmisch unerheblich ist, uber 
welchen Bus eine Verbindung gefuhrt wird. Deshalb wird vorge- 

25 schlagen, eine Busallokation dynamisch von der Hardware 

durchfuhren zu lassen und die Hardware mit einem geeigneten 
dynamsichen Busallokator zu versehen. Eine Konf iguration spe- 
zifiziert dazu nur noch, dafi sie eine Verbindung von Punkt A 
nach Punkt B innerhalb einer Zeile benotigt. Welcher der vor- 

30 handenen Busse dann tatsachlich verwendet wird, wahlt ein Ar- 
biter in der Hardware aus . Dieser kann pro Zeile entweder 
verteilt uber Nachbarschaf tsbeziehungen oder an zentraler 
Stelle fur die Zeile arbeiten. Zusatzlich konnen Busse dyna- 
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misch umgelegt werden. Dabei konnen zwei kurze nichtuberlap- 
pende Busse, die aufgrund fruherer Belegung auf unterschied- 
liche Busnummern konfiguriert wurden, bei Freiwerden von Res- 
sourcen auf dieselbe Busnummer umgelegt werden. Dadurch wird 
5 Platz geschaffen fur zukunftige langere Verbindungen . 
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Rekonf igurierbarer General Purpose Prozessor 



Patentanspruche 

1. Prozessor mit einem rekonf igurierbaren Feld von datenver- 
arbeitenden Zellen und einem :Begistermittel , dadurch ge- 
kennzeichnet, dafi das Registermittel ein Datenstromspei- 
chermittel aufweist, das dazu ausgelegt ist, einen Daten- 
strom bzw. Teile da von zu speichern. 

2. Prozessor nach dem vorhergehenden ' Anspruch, dadurch ge- 
kennzeichnet, dafi ein Registermittelalloziermittel 
und/oder ein Registermittelf reigabemittel vorgesehen ist. 

3. Prozessor nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, dafi das Registeralloziermittel dazu ausge- 
bildet ist, uber Rekonf igurationen hinweg erhalten zu 
bleiben. 
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4. Prozessor nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, dafi als Registermittel eine, gegebenen- 
falls modif izierte RAM-PAE, vorgesehen ist. 

5. Prozessor nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, dafi fur Schreib- und Lesezugriff ausgebil- 
dete Registermittel vorgesehen sind f insbesondere unter 
Implementierung eines virtuellen FIFO-Trennlinienmittels . 

6. Prozessor nach einem der vorhergehenden Anspriiche, dadurch 
gekennzeichnet, dafi weiter zumindest eine Speichereinheit 
vorgesehen ist, die zur Verwendung als Stack ausgebildet 
ist, wobei sie insbesondere dazu ausgebildet ist, einen 
Stack-Under- und/oder Overf lowzustand anzuzeigen, insbe- 
sondere einer Betriebssystemeinheit . 



